home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14705 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.6 KB  |  65 lines
  1. Newsgroups: comp.lang.c++
  2. Path: news.uunet.ca!wildcan!sq!news
  3. From: willer@carolian.com (Steve Willer)
  4. Subject: Re: auto_ptr capability question
  5. Message-ID: <3160321d.335010145@sqarc.sq.com>
  6. Sender: news@sq.com (News Administrator)
  7. Organization: Carolian Systems, Toronto ON
  8. X-Newsreader: Forte Agent .99d/32.182
  9. References: <31600aa3.1288774@news.xmission.com>
  10. Date: Mon, 1 Apr 1996 19:55:40 GMT
  11.  
  12. macron@xmission.com (Joe Schlimgen) wrote:
  13.  
  14. >Can anyone provide a reason why the designers of the STL (who, I would
  15. >think, are much more knowledgeable about C++ and OOP than I) would
  16. >choose to provide an explicit rather than an implicit function? I see no
  17. >potential problems with an implicit conversion (but I could very well be
  18. >wrong).
  19.  
  20. First of all, auto_ptr is not part of the STL. It's part of the
  21. standard C++ library. The "STL" encompasses the containers like list
  22. and vector, iterators, and algorithms such as sort() and transform().
  23.  
  24. Now, as for explicit versus implicit...it's for the same reason that
  25. std::string doesn't have an implicit conversion to "const char *":
  26. It's dangerous, and bugs can creep in undetected. I'm perfectly happy
  27. having to type a few more characters in order to avoid subtle bugs in
  28. my code. For a detailed explanation, check Meyers's "More Effective
  29. C++" book, item #5.
  30.  
  31. >Also, I've noticed that the assignment from another auto_ptr function
  32. >(also shown below) causes the auto_ptr being assign *from* to release
  33. >ownership (as it should) but does *not* delete the (possible) pointer
  34. >that is being assigned *to*, thus possibly causing a memory leak.
  35.  
  36. Ownership is being _transferred_. Note that if you have something
  37. like:
  38.  
  39. auto_ptr<T> a;
  40. auto_ptr<T> b(new T);
  41. a = b;
  42.  
  43. What this means is that at the second line, "b" owns a T, and "a" owns
  44. nothing. When you say "a=b", "a" now owns the T and "b" owns nothing.
  45. At the third line, no new T's are created -- the one T that got
  46. explicitly created is simply passed around.
  47.  
  48. >  X* get () const { return the_p; }                    // Provided by the STL
  49. >    X* operator X* () const { return the_p; }    // Not provided by the STL
  50.  
  51. You should remove this. Not only is it bad practice, but it's also not
  52. part of the standard auto_ptr.
  53.  
  54. >    void operator= (auto_ptr<X>& rhs) { reset(rhs.release()); }
  55. >    X* reset (X* p = 0) { X* tmp = the_p; the_p = p; return tmp; }
  56.  
  57. auto_ptr<T>::reset() deletes the current pointer and sets the current
  58. pointer to the given pointer.
  59. auto_ptr<T>::release() sets the current pointer to zero and returns
  60. the old value. It does _not_ delete the structure.
  61.  
  62. So, perhaps an English form of this function is "reset my own pointer
  63. with whatever the other guy released".
  64.  
  65.